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The  Autonomous  Flight  Safety  System  (AFSS)  being  developed  hy  NASA’s  Goddard 
Space  Flight  Center’s  Wallops  Flight  Facility  and  Kennedy  Space  Center  has  completed  two 
successful  developmental  flights  and  is  preparing  for  a  third.  AFSS  has  been  demonstrated 
to  be  a  viable  architecture  for  implementation  of  a  completely  vehicle  based  system  capable 
of  protecting  life  and  property  in  event  of  an  errant  vehicle  by  terminating  the  flight  or 
initiating  other  actions.  It  is  capable  of  replacing  current  human-in-the-loop  systems  or 
acting  in  parallel  with  them.  AFSS  is  configured  prior  to  flight  in  accordance  with  a  specific 
rule  set  agreed  upon  by  the  range  safety  authority  and  the  user  to  protect  the  public  and 
assure  mission  success.  This  paper  discusses  the  motivation  for  the  project,  describes  the 
method  of  development,  and  presents  an  overview  of  the  evolving  architecture  and  the 
current  status. 


I.  Introduction 

When  a  space  launch  vehicle  flies  errantly,  the  ultimate  action  available  to  those  responsible  for  the  protection 
of  property  and  public  safety  is  quick  and  certain  termination  of  the  flight.  Since  the  beginning  of  space 
flight  this  has  been  accomplished  by  tracking  the  vehicle  with  precision  radars,  returning  the  signals  to  computers  at 
a  control  center,  monitoring  its  progress  and,  if  necessary,  using  high  powered  transmitters  to  send  a  command  to 
on-board  receivers.  A  0.999  reliability  specification  requires  highly  reliable  redundant  systems.  Since  these 
systems  rely  on  line-of-sight  radio  frequency  transmissions,  as  the  vehicle  flies  down  range  additional  coverage  by 
redundant  radar  and  command  transmitters  is  required.  These  systems  must  all  be  tied  together  by  secure,  reliable 
data  communication  networks.  Maintaining  and  operating  these  systems,  often  at  isolated  locations,  has  become  a 
major  expense  to  launch  ranges  and  their  customers. 

The  average  range  cost  for  each  Atlas  or  Delta  launch  attempt  is  on  the  order  of  $500,000.  In  addition,  pre¬ 
launch  tests  of  the  Flight  Termination  System  (FTS)  cost  $100,000  and  tests  of  the  C-band  radar  tracking 
transponder  and  S-band  vehicle  telemetry  system  cost  another  $100,000  [1]. 

Mobile  Range  assets  such  as  the  one  operated  by  NASA’s  Wallops  Flight  Facility  or  the  Florida  Air  National 
Guard’s  Ballistic  Missile  Range  Safety  and  Telemetry  (BMRST)  systems  can  be  pressed  into  service  for  trajectories 
visible  to  land  areas  when  politically  and  programmatically  available.  The  small  fleet  of  deployable  assets  onboard 
ships  and  aircraft  such  as  the  Advanced  Range  Instrumentation  Aircraft  (ARIA),  and  the  Airborne  Instrumentation 
System  (AIS)  are  being  withdrawn  from  operations  due  to  high  costs  of  operation  and  maintainability.  Neither  of 
these  systems  addresses  the  needs  of  responsive  space  launch  operations.  Indeed,  scheduling  downrange  assets  for 
launch  and  testing  prior  to  launch  can  be  vexing  even  for  permanent  installations. 

When  the  expense  and  complexity  can  be  borne,  other  serious  issues  with  conventional  flight  termination 
systems  must  be  considered.  There  are,  for  instance,  launch  situations  in  which  hazards  exist  at  the  launch  site  that 
make  the  lag  time  inherent  to  human  reaction  a  critical  factor.  FTS  radio  links  have  historically  operated  on 
protected  frequencies  within  the  400-420  MHz  frequency  band.  In  the  early  1990’s  the  National 
Telecommunications  and  Information  Administration  (NTIA)  directed  400-420  MHz  frequency  band  users  to 
convert  to  narrow  band  or  move  to  another  frequency.  Due  to  high  Doppler  requirements  narrowband  is  not  feasible 
for  FTS.  The  Department  of  Defense  (DoD)  was  directed  by  NTIA  to  discontinue  use  of  416.5  MHz,  a  traditional 
frequency  without  interference  issues,  and  move  to  420-430  MHz  which  is  under  military  control  but  includes  high 
power  radar  frequencies.  These  radars  have  been  observed  to  cause  temporary  inability  to  send  termination 
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commands  to  flying  vehicles  if  it  had  been  necessary  to  do  so.  Recent  efforts  concerning  transition  to  the  encrypted 
Enhanced  Flight  Termination  System  (EFTS)  would  prevent  termination  commands  from  being  maliciously  or 
errantly  sent  to  a  vehicle  during  nominal  flight  but  would  not  overcome  radio  frequency  interference  risks  [2]. 

Flypersonic  flight  poses  particular  difficulties  for  traditional  tracking  and  termination  systems.  Whether 
performed  for  weapons  testing  or  scientific  investigation,  hypersonic  research  often  requires  long  periods  of  flight  at 
low  altitudes,  usually  over  open-ocean.  Temporary  placement  of  three  to  five  tracking  stations  may  be  required  to 
maintain  line  of  sight  communication  with  the  flight  vehicle. 

II.  Autonomous  Flight  Termination  As  A  Solution 

As  noted  previously,  the  basic  approach  to  flight  termination  has  changed  little  over  the  past  half  century. 
Meanwhile,  technologies  have  matured  which  enable  an  entirely  new  alternative  to  the  expense  and  complexity  of 
the  present  system. 

The  Global  Positioning  System  (GPS)  enables  very  accurate  tracking  information.  GPS  has  been  used  to  track 
launch  vehicles  since  1996  and  is  increasingly  being  used  with  or  in  lieu  of  radar  [3].  Although  acceptable  by  the 
Range  Commanders  Council  (RCC)  as  a  range  safety  tracking  source,  GPS  has  a  potential  weakness  in  that  it  has 
susceptibility  to  radio  frequency  noise,  blockage,  jamming  and  signal  reduction  caused  by  plume  and  ionization.  A 
technique  frequently  used  to  mitigate  this  is  coupling  it  with  an  Inertial  Navigation  System  (INS),  another 
technology  that  has  undergone  considerable  improvement  in  recent  decades.  GPS  and  INS  are  complimentary  in 
that  each  has  a  strength  in  the  area  the  other  has  a  weakness.  Inertial  measuring  devices  are  immune  to  radio 
frequency  problems  and  capable  of  very  high  output  rates,  but  if  unaided,  are  subject  to  drift  over  time.  GPS  is  used 
to  correct  for  drift.  An  integrated  system  is  capable  of  supplying  highly  accurate  time,  position,  and  velocity 
information  at  a  high  rate. 

A  third  technological  development  unforeseen  to  inventors  of  the  traditional  ground  based  flight  termination 
systems  is  the  advent  of  computers  with  sufficient  memory  to  handle  a  set  of  mission  rules  which  may  change  based 
on  position  and  previous  flight  events.  Computers  now  have  computational  speed  to  ingest  information  from 
onboard  sensors,  predict  impact  points,  and  evaluate  the  information  with  respect  to  those  rules  within  allowable 
times  to  ensure  safe  actions  are  taken. 

AFSS  can  take  vehicle  navigation  data  from  redundant  onboard  sensors  and  make  flight  termination  decisions 
using  software-based  rules  implemented  on  redundant  flight  processors.  By  basing  these  decisions  on  actual 
Instantaneous  Impact  Predictions  and  by  providing  for  an  arbitrary  number  of  mission  rules,  it  is  the  contention  of 
the  AFSS  development  team  that  the  decision  making  process  used  by  Missile  Flight  Control  Officers  (MFCO)  can 
be  replicated  in  software. 

Although  a  truly  autonomous  system  has  no  requirement  for  telemetry  or  command,  these  features  may  be 
incorporated,  even  in  the  absence  of  ground  based  systems  through  satellite  transmission  links.  This  would  allow 
the  position  and  dynamic  conditions  at  the  vehicle  to  be  known  at  a  time  when  termination  actions  were  or  were  not 
taken. 

Autonomous  systems  must  meet  the  same  stringent  requirements  of  any  flight  termination  system.  These 
requirements  are  tailored  by  individual  ranges,  but  are  generally  specified  in  the  RCC  319-07  Flight  Termination 
Systems  Commonality  Standard.  With  cooperation  of  the  AFSS  development  team  and  the  national  range  safety 
leadership,  the  RCC  319  has  been  recently  amended  to  add  specific  references  to  requirements  for  autonomous 
systems.  Rules  for  GPS  and  INS  are  found  in  RCC  324-01  Global  Positioning  and  Inertial  Measurements  Range 
Safety  Tracking  Systems’  Commonality  Standard.  The  basic  requirements  include  specifications  for  accuracy, 
timeliness  of  data,  reliability  and  independence. 

A  few,  very  simple.  Autonomous  Flight  Termination  Systems  have  been  demonstrated.  Certain  Russian  launch 
vehicles,  including  those  launched  by  SeaLaunch,  and  the  Isreali  Arrow  are  capable  of  self  termination  based  on 
simple  parameter  measurements  such  as  pitch  and  yaw  and  violation  of  preset  azimuth  limits.  Neither  of  these  is 
deemed  sufficient  to  protect  life  and  property  except  for  over  very  remote  ocean  areas  or  provide  the  level  of 
mission  assurance  required  of  today’s  civilian  and  DoD  missions  [4]. 
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III.  NASA’s  Autonomous  Flight  Safety  System 

The  National  Aeronautics  and  Space  Administration  (NASA)  has  maintained  a  multi-center  engineering 
development  team  for  the  Autonomous  Flight  Safety  System  since  2002  in  an  attempt  to  realize  the  benefits  that 
such  a  system  could  bring  to  its  launch  operations.  Such  benefits  include  increases  in  public  safety  for  mission 
profiles  that  include  phases  of  propulsive  flight  that  cannot  be  covered  or  are  prohibitively  expensive  to  cover  with 
conventional  ground  based  telemetry  and  command  systems.  Increases  in  safety  are  also  realized  for  missions  with 
phases  demanding  flight  termination  response  times  too  quick  for  a  conventional  ground-based  human  in  the  loop 
system. 

The  NASA  AFSS  development  team  has  worked  with  the  Range  Safety  community  through  the  Range 
Commanders  Council  Range  Safety  Group  (RSG)  and  Flight  Termination  Systems  Subcommittee  (FTSC)  to 
formulate  systems  level  functional,  design,  test,  and  maintenance  requirements  specific  to  the  autonomous  aspects  of 
the  system.  The  team  has  established  an  architectural  design  and  concept  of  operations  that  achieves  compliance  to 
the  fundamental  requirements  established  by  the  Range  Safety  community.  Ground  and  flight  test  prototype  units 
have  been  built  and  tested  to  demonstrate  the 
various  aspects  of  the  AFSS  architectural 
design  and  concept  of  operations,  also 
addressing  feasibility  in  various  high 
development  risk  areas. 

NASA’s  AFSS  architecture  design  permits 
flexibility  to  adapt  to  a  variety  of  platforms. 

While  a  single  processor  with  GPS  inputs 
might  suffice  for  a  UAV,  or  a  dual  processor 
with  GPS  for  a  spinning  sounding  rocket,  GPS 
and  IMU  inputs  with  three  or  more  processors 
might  be  recommended  for  a  large  orbital 
launch  vehicle.  Thus,  the  system  architecture 
supports  inputs  from  an  arbitrary  number  of 
navigation  sensors  and  up  to  four  flight 
processors  housed  in  two  physically  separated 
chassis.  Redundancy  management  of  the 
navigation  sensors  is  accomplished  within  a 
software  module  running  on  each  of  the  flight  processors.  Redundancy  management  of  the  flight  processor  output 
functions  is  accomplished  using  redundant  Field  Programmable  Gate  Array  (FPGA)  based  custom  voting  circuits. 
The  flight  software  supports  an  arbitrary  number  of  mission  rules  established  by  Range  Safety  Authorities  using  an 
inventory  of  mle  types  taken  from  current  human-in-the-loop  operational  flight  safety  practices.  The  rules 
themselves  are  specified  in  a  user  configurable  human-readable  file,  and  are  loaded  into  the  AFSS  application  prior 
to  flight. 

AFSS  will  be  capable  of  operating  as  a  stand-  alone  termination  system.  It  will  also  be  hand-over  capable  in  that 
control  could  be  transferred  to  or  from  traditional  systems  eliminating  the  need  for  downrange  tracking  assets. 
Alternatively  it  could  be  operated  as  a  backup  to  conventional  human-in-the-loop  requiring  only  a  single  string  of 
ground  based  radars  and  command  systems. 


Figure  1.  NASA's  Autonomous  Flight  Safety  System 


AFSS  primary  features  are:  [5] 

Redundancy.  The  design  tolerates  no  single  point  of  failure  that  would  at  any  time  inhibit  the  Range  Safety 
functionality  of  the  system. 

Complete  functional  independence  from  the  launch  vehicle.  While  connections  between  AFSS  and  the  launch 
vehicle  may  be  allowed  for  non-mission  critical  functions,  or  to  enhance  system  redundancy  for  functions  not 
directly  related  to  flight  termination  assessments,  the  AFSS  is  a  stand  alone  system 

Achieve  a  reliability  of  99.9%  with  a  95%  confidence  level. 

Single  point  tolerance  with  regard  to  performance  degradation  during  flight  and  inadvertent  initiation  of  the 
termination  command. 
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Flexibility  to  be  customized  to  respect  mission  specific  requirements  from  Range  Safety  organizations. 

Built  in  capability  to  issue  telemetry  throughout  all  mission  phases  by  land  based  connections  or  by  interfacing 
with  a  apace  based  telemetry  system  (e.g.  TDRSS  use  by  implementing  the  Low  Cost  TDRSS  Transceiver 
(LCT2).) 

Accommodation  of  mission  assurance  goals  through  provision  of  green-time  computations,  avoidance  of  “quick 
trigger”  or  single  data  point  decisions,  redundant  sensors  and  other  techniques. 

IV.  Architecture 

An  endeavor  of  small,  responsive  teams  at  two  NASA  centers,  with  limited  and  at  times,  sporadic  funding,  AFSS 
has  been  developed  spirally.  The  team  includes  Range  Safety  specialists  from  DoD’s  Eastern  Range  and  NASA’s 
Wallops  Flight  Facility,  the  Wallops  Range  Chief  Engineer,  and  engineers  with  many  years  of  experience  designing, 
building  and  supporting  rocket  flight  instrumentation.  The  approach  agreed  upon  was  to  focus  resources  on  items 
that  pose  high  development  risk  and  potential  feasibility  issues  and  address  those  items  on  engineering  breadboard 
and  flight  prototype  units.  A  system  architecture  was  developed  that  allows  delay  of  certain  design  decision 
commitments  (e.g.  subsystem  redundancy  requirements)  until  deployment  on  a  specific  vehicle  from  a  particular 
range.  The  stated  goal  was  to  develop  proof  of  concept  systems  advancing  toward  a  flight  prototype. 

Experienced  flight  safety  experts  including  MFCOs,  formulated  systems  level  functional,  design,  test,  and 
maintenance  requirements  focused  on  the  autonomous  aspects  of  the  system.  Requirements,  approaches  to  meet  the 
requirements,  and  tradeoff  decisions  were  regularly  briefed  to  the  Range  Commanders  Council  Range  Safety  Group 
and  its  Flight  Termination  Subcommittee  to  secure  their  advice  and  concurrence.  Continuous  communication  has 
been  maintained  with  this  group,  multiple  launch  ranges  and  numerous  potential  users.  Many  topics  uncovered  and 
discussed  during  these  exchanges  were  later  codified  into  the  new  release  of  the  RCC  319  document. 

In  accordance  with  the  level  of  funding.  Commercial  off  the  Shelf  (COTS)  hardware  has  been  used  as  much  as 
possible.  The  goal  of  the  hardware  development  effort  has  been  to  build  a  flight  “qualifiable”  rather  than  a  flight 
qualified  system.  All  components  have  been  designed,  selected,  or  modified  to  support  functional  requirements 
such  as  redundancy,  computational  speed,  and  latency.  All  are  considered  capable  of  meeting  rigorous 
environmental  specifications  but  were  only  tested  to  flight  qualification  levels  for  vehicles  on  which  they  were 
flown.  Meeting  component  qualification  levels  was  considered  outside  the  scope  of  the  project  or  delayed  until  later 
in  the  project  to  ensure  maximum  return  on  the  limited  funding  available.  Resources  have  not  been  available  to 
optimize  the  size  or  weight  of  the  unit.  For  demonstration  purposes,  some  requirements  deemed  expensive,  yet  not 
technically  challenging  such  as  qualification  of  flight  batteries,  has  been  purposely  delayed  into  the  future.  A  total 
of  four  test  flights  are  planned.  Each  is  to  exhibit  further  maturation  of  the  design.  Two  have  been  completed. 
Another  is  scheduled  for  Fall  2008. 

Figure  2  shows  the  AFSS  functional  baseline  and  highlights  its  subsystems. 
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Figure  2.  AFSS  Block  Diagram 


AFSS  supports  interfaces  to  multiple  navigation  sensors  types.  Each  sensor  providing  state  vector  data  must  be 
sampled  at  a  rate  that  meets  Range  Safety  requirements.  The  sensor  must  maintain  lock  and  accuracy  through 
dynamic  maneuvers  such  as  acceleration  and  tumbling.  Every  sensor  must  be  qualified  through  environmental 
testing  relative  to  the  mission  to  be  flown. 

Global  Positioning  System  (GPS)  systems  and  Inertial  Measurement  Units  (IMU)  will  be  the  type  of  sensors 
used  by  the  AFSS  to  gather  navigation  data.  Any  sensor  used  in  the  system  must  interface  with  all  the  preprocessors 
used  in  order  to  provide  redundancy.  The  navigation  sensors  can  be  located  inside  or  outside  the  chassis,  and  can  be 
powered  by  the  chassis  or  receive  power  directly  from  independent  power  supplies.  In  order  to  use  a  GPS  system, 
the  AFSS  will  allocate  both  an  antenna  and  a  receiver  unit.  Where  dual  GPS  tracking  systems  are  used  as  the  only 
source  of  tracking,  each  GPS  unit  should  utilize  a  set  of  antennas  positioned  with  an  optimal  radial  offset  from  each 
other. 

Data  from  each  sensor  will  be  validated  prior  to  being  used  in  the  AFSS  algorithm.  Different  techniques  are  used 
for  the  single  sensor  data  validation: 

Validate  the  sensor  data  message  checksum 

■V  Prescreen  with  any  self-monitoring  status  indicators  included  within  the  sensor  data  message. 

■V  Perform  reality  checks  on  the  sensor  using  data  derived  from  the  navigation  message. 

■V  Verify  that  the  sensor  data  latency  is  within  the  allowed  range. 

V  Perform  sensor  validation  tests  using  user  configurable  rules 

In  addition,  a  sensor  cross  validation  algorithm  will  be  used  to  ensure  individually  validated  navigation  sensors 
are  grouped  within  an  acceptable  error  tolerance.  The  algorithm  is  structured  to  determine  which  sensors  produce 
navigation  solutions  outside  of  the  ‘main  grouping’  of  sensors  and  to  flag  those  as  invalid. 

Multiple  flight  processor  units  are  individually  interfaced  with  every  sensor  and  a  Command  Switch  Logic  and 
Interlock  Circuit  (CSLIC)  unit.  Each  unit  provides  the  means  for  power  and  data  interfacing  between  all  the  AFSS 
components. 

Current  limiting  is  provided  to  prevent  damage  to  the  Power  Supply  Unit  due  to  overload  or  short  circuit 
conditions,  and  the  recovery  occurs  automatically  on  removal  of  the  fault  condition.  In  addition,  over-  and  under¬ 
voltage  protection  is  provided  on  each  regulated  output  line.  Interfaces  are  provided  for  monitoring  the  processors 
prior  to  launch  and  allow  loading  of  necessary  flight  application  software,  flight  rules,  or  configuration  files. 

An  interfacing  board  carries  commands  from  the  processor  to  the  CSLIC  units.  There  are  different  types  of 
commands  that  can  be  relayed: 
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Flight  Processor  Enable  -  Thid  function  is  used  to  tell  the  CSLIC  how  many  flight  processors  to  expect  for 
a  given  mission. 

Flight  Processor  Monitor  -  The  Monitor  (MON)  line  is  used  to  communicate  health  status  of  the  Flight 
Processor  (FP)  to  the  CSLIC.  The  MON  line  goes  through  a  set  of  relay-like  devices  such  as  Opto- 
Isolators,  Mechanical,  Solid  State  or  Programmable  Logic  Controllers  and  command  them  open  or  closed. 
Ready-To-Launch  (RTL)  -  The  RTL  line  is  set  high  on  each  FP  as  part  of  the  normal  launch  countdown 
process.  RTL  logic  is  independently  evaluated  on  each  FP  to  permit  manual  or  automatic  launch  aborts. 
ARM  and  FIRE  -  A  two-step  action  is  implemented  to  initiate  a  destmct  action  on  each  FP.  Upon 
experiencing  a  flight  constraint  violation,  the  FP  will  set  the  ARM  line  high,  followed  by  the  FIRE  line. 

A.  Command  Switch  Logic  and  Interlock  Circnit  (CSLIC) 

The  flight  processors  independently  cross-check  and  validate  all  of  the  navigation  sensors,  update  various 
internal  state  variables,  and  output  discrete  ARM/FIRE/READY-TO-LAUNCH  functions  in  accordance  with  a  set 
of  mission  rules  loaded  prior  to  launch.  The  outputs  from  all  of  the  flight  processors  drive  redundant  ordnance 
initiation  paths  through  the  use  of  two  CSLIC  devices. 

Each  CSLIC  card  is  based  on  a  Field  Programmable  Gate  Array  (FPGA)  reconfigurable  logic  and  uses 
Electrically  Erasable  Programmable  Read-Only  Memory  (EEPROM)  to  support  automatic  loading  of  the  FPGA 
upon  application  of  power. 

The  primary  function  of  the  CSLIC  is  to  provide  a  simple,  highly  reliable  interface  between  the  outputs  of  the 
multiple  independent  flight  processors  and  the  flight  termination  system  (FTS)  ordnance  train  in  a  manner  consistent 
with  the  Range  Safety  requirements  for  fault  tolerance.  A  secondary  function  of  the  CSLIC  is  to  provide  an 
interface  between  the  AFSS  and  the  launch  vehicle  countdown  process  to  permit  an  automatic  launch  abort  if  the 
AFSS  or  one  of  its  subsystems  experiences  a  fault  prior  to  launch. 

While  on  the  ground,  the  card  can  receive  two  input  signals,  i.e.  MASTER-ARM  and  MASTER-SAFE  from  the 
Ground  Support  Equipment  (GSE).  As  a  consequence,  it  latches  or  unlatches  an  internal  ENABLE  inhibit  in  an 
ARMED  or  SAFE  state. 

During  flight,  the  card  receives  sets  of  FPL,  MON,  RTL,  ARM,  FIRE,  logic  signals  coming  from  each  single 
board  computer,  residing  either  in  the  same  or  in  different  chassis.  After  applying  the  required  voting  analysis,  it 
provides  four  output  signals,  i.e.  ENABLE-CMD,  ARM-CMD,  FIRE-CMD  and  RTL-CMD  for  driving  the  Flight 
Termination  System.  [6] 

B.  Primary  Power  Supplies 

The  AFSS  and  its  components  are  powered  by  sources  independent  from  the  Lunch  vehicle.  A  separate  battery 
must  power  each  processor  unit  and  CSLIC  pair.  The  nominal  voltage  to  be  provided  is  28V,  with  22V  and  45V  as 
accepted  lower  and  upper  limits. 


V,  Software 

A  variety  of  hardware  options  are  viable  for  autonomous  systems.  As  noted  above,  hardware  has  been  a 
secondary  focus  of  the  development  project.  The  algorithms  that  successfully  define  and  evaluate  the  mission  rules 
and  the  software  that  place  them  in  effect  is  the  essential,  truly  innovative  portion  of  autonomous  flight  termination. 

When  one  contemplates  the  variety  of  mission  rules  and  considerations  in  use  by  Range  Safety  organizations  and 
the  subtle  differences  in  approach  to  similar  missions,  it  becomes  immediately  apparent  that  in  order  for  an  AFSS  to 
be  useful,  it  must  provide  substantial  flexibility  in  the  area  of  mission  configuration.  In  the  algorithm  organization 
of  the  AFSS,  this  flexibility  is  achieved  by  generalizing  the  concepts  of  ‘mission  rules’,  ‘mission  data  entities’  and 
‘mission  modes’. 

A  mission  data  entity  is  primarily  a  data  storage  construct  referenced  by  a  mission  rule.  In  the  realm  of  range 
operations,  the  mission  data  entity  represents  a  physical  flight  corridor  boundary,  gate,  or  perhaps  a  time  dependent 
parameter  required  to  evaluate  the  status  of  a  mission  rule.  Four  basic  entities  are  supported  within  the  proposed 
framework;  boundaries,  gates  (moving  and  stationary),  data  tables  (e.g.  green-time  calculations),  and  vehicle  stage 
specific  data. 

A  mission  mode  is  an  internal  variable  indicating  status  of  an  expected  event.  Examples  of  this  include  an  AFSS 
ready-to-launch  flag.  Boolean  variables  indicating  whether  or  not  the  current  stage  is  thrusting,  and  an  orbit  flag. 
Mission  mode  variables  may  also  be  referenced  by  a  mission  mle  in  determining  whether  or  not  preconditions  for 
the  application  of  the  rule  have  been  met. 
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A  mission  rule  is  primarily  used  to  trigger  a  destruet  eondition,  but  ean  also  be  utilized  to  affeet  user  defined 
mission  modes.  Examples  of  mission  rules  linked  to  destruet  inelude  impaet  position/present  position  boundary 
limits,  gate  eonditions,  green-time  limits,  and  generie  mission  parameter  threshold  limits.  A  rule  ean  also  be  used  to 
flag  when  a  eertain  eondition  has  beeome  true  (e.g.  gate  passage)  without  raising  a  destruet  eondition.  This  flag  ean 
then  be  utilized  as  a  preeondition  for  a  rule  tied  to  destruet.  There  are  four  elasses  of  mission  rules: 

a.  The  Parameter  Threshold  Rule  allows  the  user  to  speeify  one  or  more  threshold  (or  Boolean  truth) 
eonditions  that  will  trigger  a  destruet  eondition.  This  type  of  rule  is  the  most  versatile.  It  ean  be  used  to 
implement  mission  rules  for  erratie  flight,  no  piteh  program,  no  stage  ignition,  and  low  performanee. 

b.  The  Map  Boundary  Rule  possesses  support  funetions  for  evaluating  whether  or  not  a  speeified  set  of 
vehiele  eoordinates  (present  position  or  projeeted  impaet  position)  is  inside  or  outside  of  a  simple  elosed 
eurve  deseribed  in  an  assoeiated  boundary  entity. 

e.  The  Gate  Rule  possesses  support  algorithms  for  evaluating  whether  or  not  a  speeified  set  of  vehiele 
eoordinates  (present  position  or  projeeted  impaet)  has  advaneed  beyond  a  line  deseribed  in  an  assoeiated 
gate  entity. 

d.  The  Green-Time  Rule  possesses  support  funetions  for  evaluating  whether  or  not  a  flight  eontainment  rule 
eould  be  violated  during  a  period  of  time  within  whieh  the  AFSS  software  has  reeeived  no  valid  navigation 
solution  data. 

The  flexibility  of  the  proposed  arehiteeture  results  from  the  rieh  set  of  system  modes  and  state  variables  made 
available  to  the  various  mission  rales.  Therefore,  it  is  expeeted  that  this  modest  library  of  rale  types  will 
aeeommodate  virtually  any  ELV  mission. 

Configuration  of  these  rales  with  respeet  to  mission  modes  must  not  only  assure  flight  termination  when 
warranted,  but  support  mission  assuranee.  For  instanee,  the  System  Arm/Destruet  algorithms  must  not  aetivate  the 
System-Destruet  mode  based  upon  a  single  data  point  indieating  a  Destruet  Condition.  A  lag  time  for  the  System- 
Arm  and  Destruet  modes  is  mission  eonfigurable  to  filter  out  seenarios  where  a  vehiele  quiekly  passes  into  and  then 
exits  a  Destruet  Condition.  For  eases  where  the  vehiele  rides  on  the  margin  of  a  mission  rale,  repeatedly  entering 
and  exiting  a  Destruet  Condition  within  the  programmed  lag  time,  it  is  not  aeeeptable  for  an  Arm/Destruet  ‘timer’  to 
instantaneously  reset  upon  eaeh  exit. 

Based  upon  these  eonsiderations,  a  user-eonfigurable  timer  is  used  to  affeet  the  Arm  and  Destruet  funetions.  A 
System-Destraet-Signal  timer  is  maintained  by  the  deeision  flow  algorithms.  When  a  Destruet  Condition  is 
indieated  by  one  of  the  mission  rales,  the  System-Destraet-Signal  timer  starts  an  upward  eount.  When  no  Destruet 
Condition  is  indieated,  the  System-Destraet-Signal  timer  eounts  down.  On  the  low  end,  the  System-Destraet-Signal 
timer  is  elamped  so  that  it  will  not  eount  down  below  zero.  On  the  high-end,  it  is  elamped  to  limit  the  worst  ease 
time  inerement  required  to  release  the  destruet  funetion. 

System-Arm  is  aetivated  when  the  System-Destraet-Signal  timer  exeeeds  the  user  speeified  Time-To-Arm 
threshold  value,  and  System-Destruet  mode  is  aetivated  when  the  System-Destraet-Signal  timer  exeeeds  the  user 
speeified  Time-To-Destruet  threshold  value. 

With  this  framework,  it  is  reeognized  that  the  AFSS  software  implementation  must  aeeommodate  the  user 
eonfiguration  of  an  arbitrary  number  and  variety  of  so  ealled  data  entities  and  rales  to  support  a  mission.  The  AFSS 
software  implementation  must  support  the  monitoring  of  modes  for  an  arbitrary  number  of  vehiele  stages.  The 
result  is  an  effieient,  stripped-down,  rale-based  system  flexibly  tailored  to  the  range  safety  applieation  required. 

VI.  Four  AFSS  Test  Articles 

Spiral  development  of  AFSS  is  tied  to  four  launeh  vehiele  flights,  not  eonneeted  to  vehiele  ordnanee,  eaeh 
demonstrating  ineremental  progress  of  a  test  artiele  (TA)  toward  a  qualifiable  system.  Two  of  these  flights  have 
been  sueeessfully  eompleted.  Design  is  nearly  eomplete  for  a  third  planned  for  Spring  of  2009. 

A.  TAl 

Test  Artiele  One  (TAl)  was  flown  on  a  two  stage  NASA  Sounding  Roeket  from  White  Sands  Missile  Range  on 
April  5,  2006.  It  eonsisted  of  a  single  ehassis,  dual  proeessor  unit  with  inputs  from  two  GPS  reeeivers.  The  primary 
purpose  of  this  pathfinder  flight  was  to  demonstrate  the  key  elements  of  the  AFSS  eoneept  of  operations  pertaining 
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to  pre-launch  setup,  bench  testing,  vehicle  integration,  in-vehicle  end-to-end  testing,  countdown  system  verification 
procedures,  and  flight  operations. 


Figure  3.  Test  Article  1 


Two  commercial  CA  code  GPS  receivers  provided  navigation  data:  a  Javad  JNSlOO  GPS  card  mounted  inside  the 
AFSS  enclosure  and  an  Ashtech  G12  GPS  mounted  in  its  own  enclosure  external  to  the  AFSS  enclosure.  Both 
receivers  used  data  from  a  skin-mounted  wrap-around  GPS  antenna.  The  GPS  receivers  were  programmed  to 
provide  updated  three-dimensional  position  and  velocity  measurements  at  10  Flz.  Extended-temperature  industrial- 
grade  PC104  form-factor  components  were  mounted  in  a  commercial  Parvus  avionics  enclosure.  There  were  two 
MPL  MIP405  single -board  computers,  each  with  a  PowerPC  400-MFtz-series  CPU.  Each  computer  had  Ethernet 
capability  for  Ground  Support  Equipment  (GSE)  input/output  and  four  asynchronous  serial  ports  for  connections 
with  the  GSE,  the  GPS  receivers,  and  the  vehicle’s  telemetry  system. 

Two  different  sets  of  mission  rules  were  developed  for  this  test,  one  for  each  processor.  The  set  for  Processor  #1 
(designated  as  the  nominal  processor)  was  configured  so  that  a  nominal  flight  would  not  result  in  any  flight 
termination  actions.  The  rule  set  for  Processor  #2  (designated  as  the  errant  processor)  included  three  additional  rules 
so  that  multiple  destruct  activations  would  occur  during  a  nominal  flight. 

The  errant  processor  was  to  issue  termination  commands  as  it  crossed  a  gate,  again  as  it  crossed  an  artificial 
protected  “island”  and  again  as  it  failed  to  detect  third  stage  ignition  of  the  two  stage  vehicle.  The  AFSS  was  not 
connected  to  a  flight  termination  system  and  it  could  not  initiate  any  destmct  actions.  Each  processor  interpreted  its 
rule  set  correctly  and  the  errant  processor  issued  destruct  commands  on  each  of  the  three  programmed  violations.  [7] 
The  following  rule  sets  were  tested: 

'f  Configurable  time-to-arm  and  time-to-destruct 

Pre-launch  ARM/DESTRUCT  function  verification  test 
Pre-launch  loss  of  data  detection  and  FIOLD  function 
Liftoff  detection 
'f  Stage  ignition  detection 

Instantaneous  Impact  Point  computation  and  boundary  violation  (Range  “Keep-In”  Boundary) 

Errant  flight  detection  (Flight  Azimuth  limits) 

'f  Green-time  computation 

In-flight  loss  of  data  detection  and  Green-Time  destruct 
'f  No  stage  destruct 

B.  TA2(Demo2) 
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The  second  test  article  was  flown  aboard  the  Space  Exploration  Technology  Incorporated  (SpaceX)  Falcon  1 
expendable  launch  vehicle  from  the  Reagan  Test  Site  on  March  21,  2007.  This  effort  was  partially  funded  by  the 
Defense  Advanced  Research  Projects  Agency  (DARPA)  under  the  DARPA/USAF  Falcon  Program  to  demonstrate 
Operationally  Responsive  Space  (ORS)  technologies.  This  test  article  contained  redundant  flight  processors,  a 
voting  circuit,  a  power  supply  module,  and  a  GPS  receiver  deployed  in  a  flight  qualifiable  conduction  cooled 
chassis. 

Also  flown  with  the  AFSS  chassis  was  an  externally  mounted  GPS  receiver  for  navigation  solution  redundancy 
and  a  10-Watt  Low  Cost  TDRSS  Transceiver  (LCT2)  developed  by  NASA’s  Wallops  Flight  Facility  to  demonstrate 
space-based  range  ORS  technologies  also  under  the  DARPA  Falcon  Program.  Despite  the  previous  successful 
completion  of  compatibility  testing  with  launch  vehicle  systems,  a  concern  was  raised  on  launch  day  that  LCT2 
could  potentially  interfere  with  the  vehicle  GPS.  With  insufficient  time  available  to  permit  additional  conclusive 
testing,  a  decision  was  made  by  the  Falcon  1  launch  management  team,  DARPA,  and  NASA  to  fly  with  the  LCT2 
powered  off  The  data  from  one  of  the  flight  processors  was  re-routed  through  the  vehicle  telemetry  system  so  all 
but  a  subset  of  the  detailed  data  from  the  other  was  available  for  post-test  analysis. 

This  mission  was  a  pathfinder  exercise  in  which  the  AFSS  engineering  development  team  was  able  to  apply 
many  elements  of  the  AFSS  Concept  of  Operations  within  the  integration,  test  and  launch  operations  environment  of 
an  Expendable  Launch  Vehicle. 


LCT2 


Access  Connectors 
TTB  SpaceX  Box 
GPS  Splitter-,^ 


-GPS  Switch 
Interface  Connectors 


Radstone  RT4  Chassis 
■  2  processors 
-  CSLiC 

■aUAVAD  GPS 
•  Power  Supply 


Ethernet  Box 
S 

#2  JAVAD  GPS 


TDRSS  Antenna 
Splitter 


Figure  4.  TA2  Mounted  on  SpaceX 

As  is  widely  known,  the  Falcon  1  vehicle  did  not  achieve  orbit.  The  AFSS  however  was  able  to  meet  its  test 
objectives.  These  included  successful  operation  and  post-flight  performance  characterization  of  the  AFSS  hardware 
and  software  elements.  Included  in  the  mission  mle  set  were  flight  termination  mles  established  to  replicate  Range 
Safety  Officer  judgment.  No  pre-launch  attempt  was  made  to  coordinate  the  rules  programmed  into  the  AFSS  with 
those  of  the  launch  range.  Independent  rules  allowed  the  AFSS  team  to  construct  a  rule  set  which  best  tested  the 
software.  At  most  launch  ranges,  the  Range  Safety  Operations  Plan  includes  a  mission  rule  that  calls  for  termination 
of  flight  if  the  vehicle  demonstrates  “obvious  erratic  flight”  where  in  the  judgment  of  the  Range  Safety  Officer, 
continued  flight  may  pose  unacceptable  safety  risk.  Both  processors  issued  ARM  and  FIRE  functions  associated 
with  the  anomalous  vehicle  performance  experienced  during  flight.  Using  the  available  telemetry  data,  the  team  can 
confirm  that  the  termination  command  was  issued  due  to  a  violation  of  a  moving-gate  rule  established  to  catch 
erratic  flight  from  “in-plane”  vehicle  failures.  [8] 
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Components  of  TA2  shown  in  Figure  4  inelude: 

>  AFSS  Chassis  -  Two  Radstone  IMP2A  flight  proeessors  (designated  FPO  and  FPl),  a  JNSlOO  GPS  Reeeiver, 
and  a  eustom  FPGA  based  CSLIC  mounted  in  a  Radstone  RT4  eonductive  eooled  ehassis.  This  item  was  the 
foeus  of  the  test. 

>  LCT2  -  A  NASAAVallops  Low  Cost  TDRSS  Transeeiver  was  ineluded  in  the  test  as  the  primary  means  of 
reeeiving  data  from  the  AFSS  Chassis.  Status  data  from  both  FPO  and  FPl  were  routed  through  the  LCT2  using 
a  19200-kbps  TDRSS  data  link.  Also  ineluded  in  this  data  link  was  the  full  rate  (10-Flz)  data  from  both  GPS 
reeeivers. 

>  GPS  and  Ethernet  Boxes  -  In  addition  to  the  GPS  reeeiver  mounted  within  the  AFSS  Chassis,  a  JNSlOO  GPS 
reeeiver  was  paekaged  and  mounted  externally  to  the  ehassis  in  order  to  test  the  ability  of  the  AFSS  to  negotiate 
navigation  data  from  redundant  sourees.  A  DC  bloeker  was  used  at  the  RF  input  to  prevent  the  External  GPS 
from  powering  the  Low  Noise  Amplifier  (LNA)  integrated  with  the  antenna.  A  COTS  Ethernet  switeh  was 
mounted  in  a  box  on  this  staek,  providing  faeility  for  OS  kernel,  applieation,  and  eonfiguration  file  uploading 
during  testing  and  prefiight  operations. 

>  Relay  Box  (SpaeeX  TTB)  -  A  SpaeeX  supplied  relay  box  was  used  to  perform  independent  power  switehing  of 
the  AFSS  Chassis  and  the  LCT2.  It  also  eontained  relays  to  perform  power  switehing  between  the  onboard 
batteries  (internal)  and  the  on-ground  power  supply  (external). 

>  2  eaeh  50  Pin  Conneetors  (on  standoffs)  -  The  standoff  eonneetors  held  the  power  and  ground  distribution 
busses  for  the  various  subsystems  and  provided  aeeess  to  test  points  primarily  used  during  bench  testing. 

>  GPS  Splitter  -  A  COTS  RF  splitter  was  used  to  connect  a  single  GPS  patch  antenna  with  an  integrated  LNA  to 
both  GPS  receivers. 

>  GPS  Switch  -  A  COTS  RF  switch  was  used  to  permit  insertion  of  simulated  GPS  RF  data  into  the  test  article 
during  end-to-end  functional  testing  conducted  during  test-article  build  up  and  integration  with  the  vehicle.  The 
switch  was  not  used  during  countdown  or  launch  operations. 

>  LCT2  Splitter  -  A  COTS  RF  splitter  was  used  to  direct  the  S-band  telemetry  data  from  the  LCT2  to  two  patch 
antennas  mounted  on  the  vehicle  skin. 

>  Interface  Connectors  -  All  off-deck  I/O  and  power  signals  were  routed  through  the  interface  connectors.  These 
included  EGSE  controlled  signals,  power,  and  an  interface  with  the  SpaeeX  Falcon  1  telemetry  system. 

C.  TA3 

A  third  test  article  is  currently  being  built  for  a  planned  sounding  rocket  launch  in  Fall  2008  from  Wallops 

Island,  VA.  TA3  addresses  various  lessons  learned  from  Demo  2  and  makes  several  steps  toward  the  final  design 

goal  of  a  unit  meeting  all  requirements  as  a  flight  termination  system. 
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AFSS  TEST  ARTICLE  3  (PRELIMINARY) 


13.00 


APPROXIMATE  WEIGHT:  90  -  100  LBS 
CG  FRCW  AFT  JOINT:  16.5  INCHES 
IROLL:  .88  SLUG-FT* 

IPITCH:  1.25  SLUG-FT 


Figure  5.  TA3  Experiment  Section 


Advancements  planned  for  TA3  include: 

Add  a  GPS/IMU  solution.  The  AFSS  team  has  written  a  Kalman  Filter  to  integrate  a  Javad  100  GPS 
receiver  and  a  Honeywell  HG  1700  inertial  measurement  unit.  Testing  has  been  performed  on  an  F-104 
aircraft. 

The  Radstone  flight  processor  used  on  TA3  required  a  great  deal  of  work  to  overcome  its  sensitivity  to  high 
vibration  levels.  It  was  flown  with  shock  dampeners.  The  backplane  is  being  redesigned,  the  GPS/IMU 
implementation  is  being  incorporated  and  communications  between  processors  are  being  improved. 

K  Software  upgrades  will  include  additional  coding.  Safing  commands  will  be  included  and  pre-launch  test 
code  has  been  upgraded. 

A  simulated  FTS  circuit  will  simulate  actual  voltage  and  current  requirements. 

K  The  ground  support  equipment  will  have  a  modified  graphical  user  interface  to  relieve  operators  from 
manual  commands. 

K  AFSS  will  be  commanded  from  the  ground  in  and  out  of  an  inactive  mode  to  demonstrate  ability  to  hand 
over  control  to  conventional  human-in-the-loop  ground  based  systems. 

VII.  Auxiliary  Development 

In  addition  to  hardware  and  software,  several  auxiliary  developments  will  be  required  to  support  an  autonomous 
system.  These  developments  are  also  underway  at  NASA. 

Mission  Configuration  Tool:  Autonomous  action  does  not  eliminate  the  need  for  human  involvement.  It 
places  emphasis  on  the  mission  planning.  A  graphical  tool  is  required  to  assist  range  safety  officers  in 
configuring  mission  rules. 

Hardware-in-the-Loop  (HWIL)  simulation  facility:  During  development,  it  will  be  necessary  to  do 
extensive  testing  to  validate  both  software  and  hardware.  Wallops  Flight  Facility  possesses  a  state  of  the 
art  GPS  and  IMU  simulation  facility  which  can  test  mission  rules  against  nominal  and  non-nominal 
trajectories.  It  is  currently  being  upgraded  to  allow  unattended  Monte  Carlo  variation  of  trajectory  and 
performance  patterns.  It  is  envisioned  that  such  a  tool  will  be  required  to  validate  programming  before 
launches. 

GSFC  IV&V:  Internal  validation  and  verification  is  currently  being  performed  by  the  Goddard  Wallops 
Real  Time  Flight  Software  Group  in  order  to  prepare  for  submission  to  formal  NASA  IV&V. 
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GSFCAVFF  Range  Safety  Certification  Stndy:  Although  the  specifications  for  autonomous  flight 
termination  systems  have  been  defined  in  RCC  319,  the  tailoring  process  has  never  been  performed  and  no 
autonomous  system  has  been  used  on  a  range  in  the  United  States.  The  NASA  Wallops  Research  Range 
has  agreed  to  participate  in  a  tailoring  of  RCC  319  with  a  goal  of  certifying  its  use.  It  is  hoped  that  this 
pathfinder  exercise  will  aid  in  a  general  acceptance  at  other  ranges. 

Technology  transfer  initiation:  NASA’s  interest  in  AFSS  is  purely  in  research  and  development  and 
making  available  a  system  that  can  greatly  reduce  the  cost  of  access  to  space.  Two  more  developmental 
flights  are  planned  and  the  team  would  consider  briefly  filling  a  gap  for  hypersonic  vehicles  which 
absolutely  require  it.  However,  a  speedy  transition  to  a  commercial  manufacturer  of  the  units  is  planned. 

VIII.  Summary 

NASA  has  engaged  in  a  multi-year,  multi-center  development  process  to  establish  a  baseline  architecture,  a 
concept  of  operations,  and  a  detailed  design  for  implementing  an  Autonomous  Flight  Safety  System  that  achieves 
compliance  to  fundamental  requirements  established  by  the  range  safety  community. 

Two  successful  prototype  demonstrations  of  the  technology  have  been  completed  and  a  third  is  expected  in  the 
spring  of  2009.  NASA  is  now  proceeding  toward  setting  up  the  mechanisms  for  technology  transfer  of  a  working 
system. 

NASA  desires  continued  flight  test  opportunities  to  further  demonstrate  the  viability  of  the  systems  to  users  and 
the  range  safety  community.  It  is  felt  that  this  technology  will  play  a  crucial  role  in  the  ORS  vision  of  truly 
responsive  space  access  while  maintaining  public  safety. 
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